2009-11-24 2 views
1

Для этого периода оценки мой учитель CS оставил нам проект открытого выбора с участием SQL и Delphi/VB.Помогите мне с моим проектом SQL (пожалуйста)

Я закончил с назначением проектирования и создания программы, которая позволила пользователям через GUI в Delphi/VB вставить и прочитать данные ураганов, извлеченные из базы данных (кстати, последний SQL Server). Однако есть несколько уловов.

три таблицы необходимы: Ураганы, Hurricane_History и Категория

КАТЕГОРИЯ таблица не претендует быть изменен, и она содержит Min столбцы. Speed ​​',' Max. «Скорость» и «Категория». Идея заключается в том, что ураган с частотой вращения X относится к категории Y, если X находится в пределах минимальной и максимальной скорости категории Y.

Таблица ураганов предназначена для модификации конечным пользователем через Delphi/VB gui. Он содержит следующие столбцы: «Имя», «День», «Время», «Вращение», «Движение», «Широта», «Долгота» и «Фотография».

После этого есть таблица Hurricane_History, которая содержит «Имя», «Категория», «Начальное_значение», «Конечное_дальное время», «Начальная широта», «Начальная долгота», «Конечная широта», «Конечная долгота». Эта таблица не предназначена для непосредственного изменения, а автоматически заполняется через SQL (я использую триггеры SQL и хранимые процедуры).

Что должна сделать программа, так это следующее: пользователь открывает визуальное приложение и вводит информацию для определенного урагана. Поскольку только таблица Hurricanes предназначена для модификации, пользователь будет вставлять имя, день, время, текущую скорость вращения, текущую скорость движения, текущую широту, текущую долготу и, факультативно, изображение.

Если пользователь вводит ураган, который еще не существует, он создаст новый ураган с соответствующими данными в таблице Hurricane_History. Если он вводит данные для урагана, который уже существует, данные для этого урагана должны обновляться и сохраняться в соответствующей строке Hurricane_History. Кроме того, текущая категория урагана должна автоматически заполняться SQL, используя данные, которые были сохранены в таблице Category.

До сих пор, у меня есть три таблицы, столбцы, в Delphi GUI, соединения (между Delphi и SQL Server) и т.д.

Что я имею реальное трудное время, так это с SQL Триггеры и Хранимые процедуры, необходимые для генерации данных в таблице Hurricane_History. Вот мой алгоритм, первый для заполнения категории, а второй один для заполнения данных о Hurricane_History таблице:

create trigger determine_category on Hurricanes for insert, update as 
    *when a value is inserted into Hurricanes.Rotational_Speed, match it with the corresponding row in the  Categories table, and insert the corresponding category into the Category column of the hurricane's Hurricane_History row.* 

create trigger populate_data on Hurricanes for insert, update as 
    *if Hurricane.name exists, perform an update instead of an insert for using Hurricanes.Day as Hurricanes_History.Ending_Day, Hurricanes.Latitude and Hurricane.Longitude as Hurricanes_History.Ending_Latitude and Hurricanes_History.Ending_Longitude, and the Category using the determine_category trigger.* 

    *if Hurricane.name does not exist, create a record in Hurricanes_History using the data from the newly inserted Hurricane record, and populating the Category using the determine_category trigger* 

Что мне нужна помощь в переводе мои мысли и идеи в код SQL, так что я был интересно, может ли кто-нибудь захотеть мне помочь в этом.

Спасибо!

EDIT:

Я просто взбитый простую хранимую процедуру для определения категории. То, что я не знаю, как это сделать, - использовать результат/вывод хранимой процедуры как значение вставки. Кто-нибудь знает, как это сделать?

CREATE PROCEDURE determine_category 
@speed int(5) 
AS 
SELECT Category FROM Categories 
WHERE Max_Speed >= @speed AND Min_Speed >= @speed 
+0

По крайней мере, вы честны в том, что это классная работа. – Anton

+0

Все, что я ищу, - это руководство, а не полные ответы. –

ответ

4

Во-первых, поскольку вы используете SQL Server, и вы можете использовать хранимые процедуры, не используйте триггер. Это необязательно.Если ваш учитель нуждается в обосновании, вот article from SQL Server MVP Tom LaRock which discusses issues with handling triggers.

Во-вторых, насколько написано хранимые процедуры, подумайте о том, как логически обрабатывать все функции. Вы сказали, что вам нужно сделать следующее:

  • информации Читайте существующий ураган
  • Обновление информации существующий ураган
  • Вставьте новый ураган в базу данных

Ваше приложение должно обрабатывать все это как отдельные пути. И вам нужно подумать о функциональности, прежде чем писать свой первый бит кода T-SQL. Это означает, что у вас должен быть интерфейс, который представляет существующую информацию. Вам придется отображать ураганы, существующие в базе данных. Затем, как только пользователь выберет тот, чтобы получить дополнительную информацию, вам придется отбросить информацию об истории ураганов. Поэтому я знаю, что в этой ситуации у меня есть два разных метода извлечения данных на основе ввода пользователем. Это говорит мне, что мне нужно построить интерфейс GUI для логического управления этой прогрессией и отображения информации таким образом, который пользователь может использовать. И это также говорит мне, что мне нужно построить две разные хранимые процедуры. Второй будет передан некоторая информация, идентифицирующая ураган для извлечения данных (что будет основным ключом).

Теперь прокрутите остальную часть функциональности приложения. Это должно заставить вас начать.

+0

Благодарим вас за консультацию по хранимым процедурам, переход от триггеров должен встряхнуть класс довольно хорошо: D. Я, кстати, в средней школе. –

+0

У Учителя могут быть причины спросить о триггерах, в частности, возможно, чтобы проиллюстрировать, как их использовать. Не сказать, что триггеры подходят в этом случае или нет, просто скажите, что со школьными заданиями все немного размыто. –

+0

Ремус делает хороший момент. Если вам необходимо использовать триггеры, вам нужно посмотреть, как это сделать. Чтение статьи Тома поможет. Но в остальном, я думаю, большинство из нас предпочло бы иметь логику обновления хранимых процедур, а не триггеров. –

1

Вместо того чтобы использовать триггеры для этого, я был бы более склонен выполнять логические операторы DML SQL внутри транзакций. Триггеры, иногда оказывающие полезное значение, на самом деле не нужны в этом сценарии (если только они не требуются для вашей курсовой работы).

В качестве первого подхода, подумайте о том, что требуется для завершения приложения -

  • пользовательский интерфейс слой представления данных пользователю, позволяет пользователю осуществлять поиск, вставка, обновление (и, возможно, удалить) ураганный данные.

В этом слое, мы, скорее всего, хотят

пользователей 1.present со списком предыдущих ураганов, возможно, с некоторыми ключевыми деталями отображаются и дать пользователям возможность выбрать конкретный ураган и увидеть все детали.
2. Предоставьте пользователям возможность вставлять новые данные о ураганах. Подумайте о том, как категория будет отображаться пользователю для выбора и как введенные данные будут взяты с этого уровня и в конечном итоге окажутся в слое данных. Подумайте также о том, как и следует ли проверять ввод пользователя. Что нужно проверить? Что ж, гарантируя, что SQL-инъекция, эти значения находятся в допустимых диапазонах и длинах и т. Д., Если это было реальное приложение, тогда будет необходима проверка правильности ввода пользователем.

  • Уровень данных, используемый для хранения данных в определенной связи с сущностью.
  • Уровень доступа к данным, используемый для выполнения всей логики доступа к данным в отношении управления данными приложения.
  • Уровень бизнес-логики, который содержит классы, необходимые для приложения. Будет содержать любое из правил, связанных с объектами, и будет использоваться для представления данных на уровень пользовательского интерфейса.

Мы могли бы использовать чрезвычайно упрощенный подход и накладывать слой уровня пользовательского интерфейса прямо на уровень данных через хранимые процедуры (которые будут действовать как наш уровень доступа к данным, а также наш уровень бизнес-логики, поскольку они будут инкапсулировать правила, касающиеся существует ли урагановая запись уже существует и нуждается в обновлении или требуется создание новой записи, возможно, какая-то проверка).

+0

Как вы думаете, я могу использовать представление вместо таблицы для слоя Hurricanes_History? –

+0

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

-1

Re: Вставка sproc-выхода в таблицу. Используйте следующий общий синтаксис:

INSERT INTO table (field1, field2, field3) 
EXEC yourSproc(param, param) 

В документации insert, поиск execute_statement для деталей.

+0

Если вы хотите, вы собираетесь использовать sproc, вы должны просто посмотреть на INSERT внутри него, где вы берете параметры и т. д. Таким образом, вам не нужно предоставлять права INSERT для таблицы, просто ВЫПОЛНИТЕ права на хранимую процедуру. –