Ответы к экзамену по БД. 1. Архитектура базы данных. Физическая и логическая независимость (трехуровневая модель ansi). 3
 Скачать 2.24 Mb.
|
20. Системный анализ предметной области.С точки зрения проектирования БД в рамках СА, необходимо провести подробное словесное описание объектов ПрО и реальных связей, которые присутствуют между ними. В общем случае существуют два подхода к выбору состава и структуры предметной области: Функциональный подход – он реализует принцип движения "от задач" и применяется тогда, когда заранее известны функции некоторой группы лиц и задачи, которые они будут решать с помощью БД. В этом случае можно четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны. Предметный подход – информационные потребности будущих пользователей БД жестко не фиксируются. В описание ПрО включаются наиболее существенные объекты и взаимосвязи. Конструируемая БД м.б. использована при решении заранее не определенных задач. Это кажется очень заманчивым, однако приведет к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной. На практике рекомендуется использовать некоторый компромиссный вариант, который, ориентирован на конкретные задачи или функциональные потребности пользователей, НО учитывает возможность наращивания новых приложений. Системный анализ должен заканчиваться подробным описанием объектов предметной области, которые должны храниться в БД, формулировкой конкретных задач, решаемых в БД с кратким описанием алгоритмов их решения, требований со стороны пользователя, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД. 21. Инфологическое моделирование. ER - модель. Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Инфологическая модель – это формализованное описание предметной области, которое легко "читается» и специалистами по БД и ПрО. Оно должно быть достаточно емким, чтобы можно было оценить глубину и корректность проработки проекта БД. Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. ER-модель (от англ. entity-relationship model, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (англ. entity-relationship diagram, ERD, ER-диаграмма). Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.). 22. Алгоритм перехода от ER к реляционной модели данных.Правила преобразования ER-модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, сущность может быть названа «Книжный каталог", а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами). 2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него). 3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). 4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY). 5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL). |