Проект - база - данные
Cтраница 2
Системные UID позволяют не напрягаться, но формируют плохой проект базы данных. [16]
Автор предлагает ряд путей решения проблемы оценки качества проекта базы данных, которая остается до сих пор одной из сложных задач. Предлагаемая методика проектирования представляет собой итеративный процесс, организованный в виде последовательности применения определенных технических приемов и процедур с многочисленными точками принятия решений. Хотя автор постоянно говорит о преимуществах автоматизации многих процедур, материал изложен так, что является конструктивным и полезным независимо от того, применяется или не применяется ЭВМ в качестве вспомогательного инструмента проектировщика. Более того, автор подчеркивает ( и с этим нельзя не согласиться), что процесс проектирования баз данных в принципе не может быть сделан автоматическим, так как для решения многих сложных проблем участие человека является обязательным. [17]
Заключительный этап планирования проекта базы данных предполагает аудит конечного физического проекта базы данных, гарантирующий правильность решений, принятых группой разработки. [18]
И все же остается вопрос: какой уровень аудита проекта базы данных достаточен до построения модулей. Если переносятся данные старой системы, то, возможно, полный аудит базы данных не потребуется. Но тогда нужно будет убедиться в том, что процессы фаз проектирования и построения завершены правильно. Следовательно, необходимо проверять, хотя бы выборочно, произвольным образом, действия каждого разработчика на этих фазах. Если недостатки в работе одного или нескольких из них становятся очевидны или если нет системы, из которой можно было бы перенести данные, то, скорее всего, понадобится более тщательный аудит. [19]
В данной главе рассмотрен аналитический метод оценки времени ввода-вывода для проекта базы данных. Напомним читателю, что база данных все еще остается проектом на бумаге и технически не реализована. Цель предложенного метода состоит в уменьшении числа вариантов проекта в результате приближенной оценки общего времени, затрачиваемого на операции ввода-вывода. [20]
К этом) моменту жизненного цикла разработки системы уже созданы основа проекта базы данных и макеты экранов, или доски хранения, приложений. По окончании этапа прикладного проектирования проект базы данных будет полностью завершен и готов к построению базы данных и приложений. [21]
Этот отчет - последний в серии из трех работ, посвященных проекту ЭВМ базы данных. [22]
С точки зрения базы данных рабочая среда Oracle сдвигается к объектно-ориентированной модели и проекты баз данных становятся все более и более объектно-ориентированными. [23]
Проектировщик баз данных ( database designer) строит логические модели и физически реализует проекты баз данных. [24]
 |
Оценка вероятностей РСЮ, РТЮ и РРЮ. [25] |
Введенные выше понятия вероятностей выполнения операций ввода-вывода позволяют в некотором смысле оценить варианты проекта базы данных. Однако полная оценка качества проекта базы данных невозможна без его оценки в контексте с предполагаемым использованием базы данных. Следовательно, далее необходимо оценить схемы вызовов системы DL / 1 и время предполагаемых операций ввода-вывода. [26]
На этапе прикладного проектирования определяются детальные характеристики использования столбцов в каждом из модулей, а также подтверждается проект базы данных. Изменения, вносимые во время проектирования, могут казаться простыми и довольно прямолинейными; однако их обычно сопровождает так называемый совокупный эффект. Вполне возможно, что каждое отдельное изменение будет оказывать минимальное воздействие или стоить немного, но общий эффект от множества таких изменений может быть весьма существенным. Руководитель процесса должен оценивать изменения, определяя, будут ли они влиять на время, стоимость или качество разработки. Самое важное при этом - тщательно следить за соблюдением приоритетов изменений и за их воздействием на пользователя / заказчика / клиента. [27]
Для базы данных на фазе построения можно выполнить отчет Database Table and Index Size Estimates ( оценка размера таблиц и индексов базы данных) из группы Database and Network Design ( проект базы данных и сети), еще раз проверив оценочный размер завершенной системы базы данных. Помимо этого, в группе Server Model Definition ( описание модели сервера) предлагается отчет Invalid Database Objects Quality Control ( контроль качества недостоверных объектов базы данных), который применяется для проверки объектов базы данных на наличие каких-либо недостатков. Отчет Column Change Impact Analysis ( анализ последствий изменения столбцов) информирует, в каких модулях используется указанный столбец. Это полезно в тех случаях, если необходимо знать, на какие модули повлияет изменение столбца. Это позволяет проверить последствия изменений, а также получить общую картину отображения столбца в разных модулях. [28]
Язык DML представляет собой расширенный вариант языка ФОРТРАН. В проектах базы данных КОДАСИЛ область определена недостаточно четко. В Абердинской системе управления банком данных экземпляры записи некоторого типа могут быть помещены только внутри одной области. Описание записи проводится в терминах операторов описания данных языка ФОРТРАН. [29]
В SPICE перечислены не все возможные инженерные рабочие продукты, причем это касается не только иерархии целевой Системы, представленной избранными компонентами, но и промежуточных документов. Например, выделяется Проект Базы данных ( Database Design), но ничего не говорится относительно целевой Базы данных и относительно проектов, выделяемых компонентов Системы. [30]
Страницы: 1 2 3 4