OK, I think I know what you mean now. Looking at the columns I think you were thinking lookup tables, not normalizing columns out of the Ticket table based on the TicketNumber.

Something like this for moving Priority out of the Ticket table?

CREATE TABLE dbo.TicketPriority (

TicketPriorityID TINYINT NOT NULL

CONSTRAINT [PK_dbo.TicketPriority] PRIMARY KEY CLUSTERED,

-- renamed TicketPriority because Priority is a keyword

Name VARCHAR(100) NOT NULL);

GO

CREATE UNIQUE INDEX [IX_dbo.TicketPriority.Name] ON dbo.TicketPriority (Name); -- alternate key

GO

CREATE TABLE dbo.Ticket

(

TicketNumber INT NOT NULL CONSTRAINT [PK_dbo.Ticket] PRIMARY KEY CLUSTERED,

TicketPriorityID TINYINT NOT NULL, -- refactored into lookup table

Assignee VARCHAR(25) NULL,

Category VARCHAR(25) NULL,

VendorTicket VARCHAR(60) NULL,

OpenDate DATE NULL,

Opener VARCHAR(30) NULL,

Closer VARCHAR(30) NULL,

CONSTRAINT [FK_dbo.Ticket_dbo.TicketPriority.TicketPriorityID]

FOREIGN KEY (TicketPriorityID)

REFERENCES dbo.TicketPriority (TicketPriorityID));

Note: I agree with Chrissy on the naming and some of those changes are reflected in my sample code. I hadn't even dove into the table column names themselves until just now, I was still thinking about the design question of how to split the table. I also went singular on the table name and changed Priority to TicketPriority since Priority is a keyword. I tend to have better luck using singular table names especially when it comes time to create linking-tables, e.g. in my opinion a table named TicketVenue sounds better than TicketsVenues.