Этапы жизненного цикла базы данных. Понятие проектирования базы данных

Понятие проектирования базы данных. Требования, предъявляемые к базе данных.

Проектирование БД – процесс создания проекта БД, предназначенной для поддержки функц-я эк о и способствующей достижению его целей. Требования: целостность БД – требование полноты и непротиворечивости данных; многократное использ данных; быстрый поиск и получение инфы по запросам пользователей; простота обновления данных; уменьшение излишней избыточности данных; защита данных от несанкционированного доступа, искажения и уничтожения.

Этапы жизненного цикла базы данных.

Жизненный цикл БД – процесс проектирования, реализации и поддержки БД. Состоит из 7 этапов: 1 предварит планирование (собирается инфа о программах и файлах, помогающ установить связи с текущ приложен, позвол определ будущ требов к БД. Инфа документ-ся в виде обобщен концептуал модели данных);

2 проверка осуществимости (подготовка отчетов по 3 вопр: есть ли технология, персонал и средства для успешн осущ-ния плана созд БД, эк эффективность);

3 определение требований (цели БД; инф потребности различ структур подразделений и их руководит; требования к оборудованию, к ПО);

4 концептуальное проектирование (созд подробн модели пользовательских представлений данных, затем они интегрируются в концептуал модель, кот фиксирует все элементы корпоратив данных, подлежащих загрузке в БД);

5 логическое проектирование (выбор типа модели данных);

6 физическое проектирование (логич модель расшир характ-ками, необход для определения способов физич хранения БД, типа устройств для хранен, методов доступа к данным базы, требуемого объема памяти);

7 оценка работы и поддержка БД (что не учли, внесен изменен, доб новые данные, разработка новых приклад программ, работающ с БД)

 

22. Модель "сущность-связь", ее понятия: сущность, атрибут, экземпляр сущности, связь, мощность связи. Представление сущности и связи на ER-диаграмме.

Модель "сущность–связь" (ER-модель) - средство модел-ния предметной области на этапе концептуальн проектир. В ней модел-ние базир на исп графич средств – ER-диаграмм. Они предст-ют связи между сущностями. Сущность – некоторый объект реал мира, кот может сущ-ть независимо. Сущность имеет экземпляры, отлич-ся друг от друга значениями атрибутов и допускающие однозначную идентификац. Атрибут – это св-во сущности. Напр, сущность КНИГА характ-ся такими атрибутами, как автор, наименование, цена, издательство, тираж, кол-во стр. Конкретные книги - экземпляры сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом "наименование". Атрибут, кот уникал образом идентифицирует экземпляры сущности - ключ. Может быть составной ключ, представл комбинацию нескольких атрибутов. На ER диагр сущность предст-ся прямоугольн, в кот указ-ся ее имя.Сущ-ют связи между сущностями. Связь - взаимодействие между сущностями. Она характ-ся мощностью, кот показ, сколько сущностей участвует в связи. На ER-диаграмме связь изобр-ся ромбом.

 

25.Правила преобразования ER-диаграмм в реляционные таблицы в случае связи 1:1.

Правила опираются на 2 осн фактора – тип связи и класс принадлежности сущности. Правило1: Если связь типа 1:1 и класс принадл обеих сущностей явл обязательным, то нужна только одна табл. Первичным ключом этой таблицы может быть первичный ключ любой из двух сущностей. ПР.2:Если связь типа 1:1 и класс принадлежности одной сущности явл обязательным, а другой – необязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности, для кот класс принадлежности явл необязательным, добавляется как атрибут в таблицу для сущности с обязательным классом принадлежности. ПР.3: Если связь типа 1:1 и класс принадлежности обеих сущностей явл необязательным, то нужно построить 3 таблицы – по 1 для каждой сущности и 1 для связи. Первич ключ сущности должен быть первич ключом соответств таблицы. Табл для связи среди своих атрибутов должна иметь ключи обеих сущностей.