Области приложений, в к-рых достаточно испол-ть файлы, и для к-рых необходимы бд.
Файлового способа орг-ции данных имеет ряд недостатков:
А) Зав-ть данных от приложений. Файлы данных обычно жестко привязаны к программному обеспечению. Испол-е их возможно только вместе с соотв приложениями. Это, во-первых, ограничивает сферу испол-я данных: они не могут испол-ться в тех узлах вычислительной системы, где не установлено соотв программное обеспечение. Во-вторых, ограничены возможности обработки инф-и; они полностью исчерпываются алгоритмами, заложенными в материнской программе, а разработка нового программного обеспечения на базе существующих файлов весьма затруднено, так как описания данных и их структуры опять же хранятся внутри материнской программы.
Б)Трудоемкость внесения изменений. Как уже говорилось, любые изменения в структуре инф-и требуют соотв изменения программного обеспечения, т.е, фактически, включают этап допол программирования. Это ставит пользователя в зав-ть от разработчиков программного обеспечения и в значительной мере увел-ет затраты на поддержание работоспособности автоматизированной информационной системы. Положение еще более усложняется, если одни и те же файлы испол-тся неск приложениями – в этом случае потребуется переработка всех связанных программных средств.
В) Избыточность инф-и и дублирование данных. Очевидно, что разные программные ср-ва могут испол-ть одну и ту же инф-ю, например, нормативно-справочные данные. Но, поскольку каждое приложение испол-ет файлы данных соб формата, приходится дублировать эту инф-ю для каждой из использующих программ. Это, с одной стороны, увеличивает непроизводительные затраты на хранение и испол-е излишней инф-и, с другой стороны, увел-ет расходы на программирование, поскольку в различных программах повторяются одни и те же процедуры обработки данных. Наконец, это приводит к допол трудовым и материальным затратам при внесении любых изменений в данные, так как эту процедуру приходится повторять для каждого из приложений.
|
|
|
Г) Разобщение данных. Файлы данных, используем разными приложениями, не связаны или только частично связаны между собой. Это зачастую приводит к невозм-ти получить полную картину состояния предметной области, серьезным затруднениям при решении эк задач, требующих работы с данными разных программ. Кроме того, это может вызывать временную или постоянную противоречивость данных, нарушение их целостности.
Д) Не оперативность инф-и. Дублирование, переработка большого числа файлов, отсутствие целостности приводит к значит снижению оперативности всей информационной системы.
Если нас устраивают его недостатки, например у нас нет приложений, редко вносим изменения, неважно дублирование данных, то можно испол-ть файловый метод. В иных случаях – БД.
|
|
|
Принципы нормализации, на к-рых основан классич подход к проектированию реляц бд.
Под нормал-цией понимается попытка предотвратить аномалии обновления реляц таблиц, т.е. ситуации к-рые могут привести к противоречности данных.В теории реляц бд обычно выделяется след посл-ть нормальных форм:
1. первая нормальная форма (1NF) – атомарности атрибутов
2. вторая нормальная форма (2NF) - каждый неключевой атрибут должен функционально полно зав-ть от первичного ключа
3. третья нормальная форма (3NF) - между не ключевыми атрибутами сущности должны отсутствовать транзитивные зависимости
4. нормальная форма Бойса-Кодда (BCNF) - любая функциональная зав-ть между его полями сводиться к полной функциональной зав-ти от возможного первого ключа;
5. четвертая нормальная форма (4NF);
6. пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).
Процесс нормал-ции закл-ется в разложении (декомпозиции) исх отн-ний БД на более простые отн-ния. Каждая ступень этого процесса приводит схему отн-ний в послед нормал формы. Нормал-ция позволяет удалить из таблиц избыточную неключевую инф-цию.
|
|
|
Реляц модель данных. Общая характеристика. Целостность сущности и ссылок.
См 7,9,13
Проектирование реляци баз данных с испол-ем Case-технологий (пакет ErWin).
В реляц даталог модели инф-я представляется в виде прямоуг таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникал внутри бд. Таблица отражает тип объекта реал мира - сущность, а каждая ее строка 1 конкретн объект - экземпляр сущности. Каждый столбец таблицы имеет уникал для своей таблицы имя. Столбцы расположены в таблице в соотв-и с порядком след-я их имен при ее создании. Таблица не может иметь менее 1 столбца. В каждой таблице реляц модели д б столбец или сов-ть столбцов, значения к-рых однозначно идент-ют каждую строку таблицы. Этот столбец или их сов-ть и называется первичным ключом таблицы. Если таблица удовл-ет требованию уникал-ти первичного ключа, она называется отн-ем. В реляц модели все таблицы д б преобразованы в отн-я. Отн-я реляц модели связаны между собой. Связи поддерживаются внешними ключами. Внешний ключ это столбец (сов-ть столбцов), значение к-рого однозначно хар-ет значения первичного ключа другого отн-я.
Для построения ER-диаграммы:
1)Обозначим названия таблиц – сущности, колонки в таблице – атрибутами сущности, а экземпляр атрибута сущности – конкретная запись в колонке.
2)Диаграмма строиться на уровне сущностей, т.е. сущности изображаются прямоугольниками и размещаются имена сущностей внутри этих прямоугольников. Прямоугольник с округленными вершинами – дочерняя сущность – это таблица, в которой расположен внешний ключ, без – родительская с первичным члючом. Между сущностями проводятся линии, отмечающие связи, даются имена этим связям, а также указываются мощности.
Дата добавления: 2018-05-09; просмотров: 235; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!