А еще я в нее ем.
БД - база данных
СУБД - система управления базами данных
ФС - файловая система
Б1В1.
1)
DEF:БД - организованная совокупность поименнованых взаимосвязанных данных, предназначенных для многократного использования многими
пользователями/приложениями.
DEF:БД — это совокупность взаимосвязанных данных (интегрированность), при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для многих приложений.
DEF:СУБД - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
2)
Функции ОС для работы с файлами -> Файловые системы -> Табличные процессоры -> СУБД
Пусть есть файл F1:
|A|B|C|D|E|
Этот файл используют несколько законченных приложений. Одному из приложений требутся данные и новые поля (F и G). Возможны три варианта развития.
В1)
Необходимо вставить новые поля в структуру файла:
|A|...|F|E|
Это повлечет за собой переписывания приложения, как минимум, в месте ввода/вывода данных.
Недостаток ФС - "эффект спагетти". Необходимость переписывать существующий код.
В2)
Необходимо скопировать данные из файла F1 и добавить поля F и G.
Проблема - избыточность данных. Есть вероятность, что данные в файлах будут находиться на разных стадиях обновления. Удобно, когда данные используемые в приложениях хранятся в одном месте. Также, тратится дополнительная память на хранение избыточных данных.
В3)
В файл F2 копируются только ключи из F1.
|Id|A|B|C|D|E|
|Id|F|E|
Основная проблема - негибкость.
Несмотря на то, что этот подход схож с тем что используется в реляционных БД, а избыточность данных минимальна, функциональные связи между полями не учитываются при разнесении полей в таблицы. Разнесение полей по разным таблицам вызвано необходимостью добавлять новые поля. При необходимости добавления новых полей число файлов будет множится.
ВЫВОД:
В случае ФС разработчик сам должен писать вспомогательные функции, к-рые будут собирать данные об объекте из разных файлов, учитывая структуру и сортировку. ПО - неунифицированное, обращении к одному файлу и к совокупности отличается -> негибкий подход.
В БД данные, храняющиеся в разных таблицах, связываются и контролируются на предмет нарушения целосности, единым управляющим механизмом, который не нужно программировать. Так же в СУБД существуют декларативные языки запросов высокого уровня, позволяющие специфицировать то, что нужно найти не программируя.(НПР SQl - вопреки всеобщему заблуждению, SQL - информационно-логический язык, а не язык программирования)
SQL:
- DDL - определение данных
- DML - манипуляция данными
- DCL - контроль данных
Основная причина недостатков работы с файлами традиционными средствами: в традиционном подходе данные хранятся совместно с программами. В БД - данные и приложения, работающие с этими данными, отделены друг от друга. Данные хранятся и управляются независимо от программ.
Данные структурируются так, чтобы наращивать приложение мб без изменения исходного кода. Так же требуется простота реорганизации и реструктуризации.
DEF: Реструктуризация подразумевает как изменение в структуре уже существующих данных, так и добавление новых таблиц и связей.
В случае СУБД при условии правильно выполненной нормализации данных, реструктуризация не приводит к необходимости внесения изменений в ранее написанный программный код системы.
Для того чтобы реализовать независимость данных от прикладных программ, современные СУБД имеют многоуровневую архитектуру, которая позволяет поддерживать независимость данных не только на логическом, но и на физическом уровне. А в файловых системах описание данных не отделено от их использования, что приводит к вышеперечисленным недостаткам.
DEF: Реогранизация данных помимо реструктуризации подразумевает изменение расположения данных на внешних носителях или даже переход от централизованной к распределенной БД, когда одна БД хранится не централизованно, а на разных серверах.
DEF: Независимость данных - измение данных не приводит к изменению ПО и наоборот.
СУБД - система управления базами данных
ФС - файловая система
Б1В1.
1)
DEF:БД - организованная совокупность поименнованых взаимосвязанных данных, предназначенных для многократного использования многими
пользователями/приложениями.
DEF:БД — это совокупность взаимосвязанных данных (интегрированность), при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для многих приложений.
DEF:СУБД - это совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.
2)
Функции ОС для работы с файлами -> Файловые системы -> Табличные процессоры -> СУБД
Пусть есть файл F1:
|A|B|C|D|E|
Этот файл используют несколько законченных приложений. Одному из приложений требутся данные и новые поля (F и G). Возможны три варианта развития.
В1)
Необходимо вставить новые поля в структуру файла:
|A|...|F|E|
Это повлечет за собой переписывания приложения, как минимум, в месте ввода/вывода данных.
Недостаток ФС - "эффект спагетти". Необходимость переписывать существующий код.
В2)
Необходимо скопировать данные из файла F1 и добавить поля F и G.
Проблема - избыточность данных. Есть вероятность, что данные в файлах будут находиться на разных стадиях обновления. Удобно, когда данные используемые в приложениях хранятся в одном месте. Также, тратится дополнительная память на хранение избыточных данных.
В3)
В файл F2 копируются только ключи из F1.
|Id|A|B|C|D|E|
|Id|F|E|
Основная проблема - негибкость.
Несмотря на то, что этот подход схож с тем что используется в реляционных БД, а избыточность данных минимальна, функциональные связи между полями не учитываются при разнесении полей в таблицы. Разнесение полей по разным таблицам вызвано необходимостью добавлять новые поля. При необходимости добавления новых полей число файлов будет множится.
ВЫВОД:
В случае ФС разработчик сам должен писать вспомогательные функции, к-рые будут собирать данные об объекте из разных файлов, учитывая структуру и сортировку. ПО - неунифицированное, обращении к одному файлу и к совокупности отличается -> негибкий подход.
В БД данные, храняющиеся в разных таблицах, связываются и контролируются на предмет нарушения целосности, единым управляющим механизмом, который не нужно программировать. Так же в СУБД существуют декларативные языки запросов высокого уровня, позволяющие специфицировать то, что нужно найти не программируя.(НПР SQl - вопреки всеобщему заблуждению, SQL - информационно-логический язык, а не язык программирования)
SQL:
- DDL - определение данных
- DML - манипуляция данными
- DCL - контроль данных
Основная причина недостатков работы с файлами традиционными средствами: в традиционном подходе данные хранятся совместно с программами. В БД - данные и приложения, работающие с этими данными, отделены друг от друга. Данные хранятся и управляются независимо от программ.
Данные структурируются так, чтобы наращивать приложение мб без изменения исходного кода. Так же требуется простота реорганизации и реструктуризации.
DEF: Реструктуризация подразумевает как изменение в структуре уже существующих данных, так и добавление новых таблиц и связей.
В случае СУБД при условии правильно выполненной нормализации данных, реструктуризация не приводит к необходимости внесения изменений в ранее написанный программный код системы.
Для того чтобы реализовать независимость данных от прикладных программ, современные СУБД имеют многоуровневую архитектуру, которая позволяет поддерживать независимость данных не только на логическом, но и на физическом уровне. А в файловых системах описание данных не отделено от их использования, что приводит к вышеперечисленным недостаткам.
DEF: Реогранизация данных помимо реструктуризации подразумевает изменение расположения данных на внешних носителях или даже переход от централизованной к распределенной БД, когда одна БД хранится не централизованно, а на разных серверах.
DEF: Независимость данных - измение данных не приводит к изменению ПО и наоборот.